Development of computer code, such as for a software product, often involves the work of multiple developers who may or may not have significant interaction with each other, and who may be geographically dispersed. Considerations such as these may lend significant complexity to the development process because it is difficult for the developers to interact with each other, and to coordinate their respective efforts.
Related technological problems with typical coding processes concern the fact that it is often the case that some portions of code in development rely on, or otherwise relate to, other portions of code that are also in development. That is, the various code portions being developed are interrelated with each other in some way. Consequently, the code being developed by one developer can cause errors and other problems in the software product if the relation between the code portions is not properly accounted for. To illustrate, a code development environment may employ a variety of different teams, totaling over 100 developers, with each team writing code and adding new tests. As a result, it is challenging to integrate and add regression to existing code during development. As well, if one or more regression defects are found, it is time consuming to revise the code and execute any applicable tests on the revised code.
Still another technological problem commonly encountered in typical code development processes and environments is that it is difficult, or impossible, to determine what the effect of a change in one code portion will have on other, related, code portions. That is, developers lack effective tools to determine what the potential risks are to other portions of the software if a change is made to code being written by that developer.
A related technological problem presented by typical code development processes and environments is that a developer generally does not have a way to usefully interact with owners of dependent code portions to assess risks of code changes implemented by the developer. Thus, developers may simply have to make their best guess as to what the impact might be that results from changes that they are planning to implement in the portion of code that they are developing.
As well, due to technological problems such as those already noted, and others, testing of code often does not take place until after the various code portions have been submitted by developers for inclusion in the software product. As a result, problems in the software portions may not come to light until a relatively late stage in the development process.
Moreover, the testing approach noted above has proven problematic as well. In particular, it is often the case that multiple test procedures are developed and implemented that are duplicates of each other. Thus, time and effort are wasted on development and use of test procedures that are not needed.